Skip to content

Release: main → prod (2026-07-09) - #1532

Merged
rlho merged 3 commits into
prodfrom
main
Jul 9, 2026
Merged

rlho merged 3 commits into
prodfrom
main

Conversation

@rlho

@rlho rlho commented Jul 9, 2026

Copy link
Copy Markdown
Collaborator

Summary of Changes

Ships #1502 (Entra ID client_credentials token mode for the NYU API) to production. This is the only change between prod and main.

Why now: NYU IT migrated identity-v2-sys to Entra ID during the July 8 migration window (3–5pm EDT). The API gateway now rejects WSO2 tokens with 400 "Token format is not valid.", so production identity fetches have been failing on cache misses since 4:33pm EDT on July 8 (first affected users: efh257, jyl9645, nw2289). The 7-day Firestore identity cache is absorbing most of the impact, but coverage shrinks daily as entries expire.

Configuration is already in place (verified against the live API):

  • Repo secrets NYU_ENTRA_CLIENT_ID / NYU_ENTRA_CLIENT_SECRET are set.
  • Repo variable NYU_API_AUTH_PROVIDER=entra is set, so this deploy switches token acquisition to Entra.
  • NYU granted our Entra client (MuleSoft_Booking App_EID) access to identity-v2-sys on July 8: a live Entra token now returns 200 with real identity data (401/403 before the grant). The api_access_id query parameter is still required post-migration and the code already sends it.
  • The WSO2 path remains the code default when NYU_API_AUTH_PROVIDER is unset, but WSO2 tokens are permanently rejected by the API, so the flag flip is what restores service.

Schema Changes

  • No tenant schema changes
  • Schema changed (describe below)

Checklist

  • I linked relevant issue(s) in the Development section
  • I checked for existing implementations and confirmed there is no duplication
  • I thoroughly tested this feature locally
  • I added or updated unit tests (or explained why not in the PR description)
  • I attached screenshots or a video demonstrating the feature (or explained why not in the PR description)
  • I incorporated Copilot's feedback (or explained why not in the PR description), and marked conversations as resolved
  • I confirmed my PR passed all unit and end-to-end (E2E) tests
  • I confirmed there are no conflicts
  • I requested a code review from at least one other teammate

Screenshots / Video

Backend-only change (NYU token endpoint); no UI. Verification against the live NYU API is described above; unit tests for both provider paths are in tests/unit/nyuApiAuth.unit.test.ts (see #1502).

rlho added 3 commits June 15, 2026 12:37
NYU IT is migrating API auth from WSO2 to Microsoft Entra ID. Add a
dual-mode token path in nyuApiAuth: default keeps the WSO2 password
grant; NYU_API_AUTH_PROVIDER=entra switches to the Entra
client_credentials grant. Deploy workflows pass through the new
provider flag and Entra client id/secret. Default behavior is
unchanged until the flag is set.
feat(auth): add Entra ID client_credentials token mode for NYU API
@github-actions

github-actions Bot commented Jul 9, 2026

Copy link
Copy Markdown

Tenant Schema Diff (development → production)

This PR targets prod. Review the diff below and confirm every change is acceptable before merging.

Key Differences by Document

📄 Document: itp
   Added keys (1)
     + termConfig
   Deleted keys (0)
   Updated keys (2)
     ~ attestations
     ~ resources
📄 Document: mc
   Added keys (1)
     + termConfig
   Deleted keys (0)
   Updated keys (2)
     ~ attestations
     ~ resources
Full dry-run output
🚀 Starting collection copy process...
📊 Options: {
  sourceCollection: 'tenantSchema',
  targetCollection: 'tenantSchema',
  sourceDatabase: 'development',
  targetDatabase: 'production',
  dryRun: true,
  reportFile: 'dry-run-pr-production-details.json'
}
📊 Using database names: {
  development: 'default',
  staging: 'booking-app-staging',
  production: 'booking-app-prod'
}
📡 Connected to source database (development -> default)
🔍 Testing connection to default...
✅ Successfully connected to default

🔍 [DRY RUN] Would back up 2 tenantSchema documents in booking-app-prod to tenantSchemaBackup
  📄 Would create backup document: tenantSchemaBackup/itp-backup-copy-2026-07-09_02-23-17-819
  📄 Would create backup document: tenantSchemaBackup/mc-backup-copy-2026-07-09_02-23-17-819

📦 Step 2: Copying tenantSchema to tenantSchema...

🔍 [DRY RUN] Analyzing tenantSchema to tenantSchema in booking-app-prod...
🔍 Testing connection to booking-app-prod...
✅ Successfully connected to booking-app-prod
📋 Found 2 tenantSchema documents to copy
📋 Found 2 existing tenantSchema documents in target
🔎 Calculating key-level diffs...

📄 Document: itp
   Target exists: yes
   Added keys (1)
     + termConfig
   Deleted keys (0)
   Updated keys (2)
     ~ attestations
     ~ resources

📄 Document: mc
   Target exists: yes
   Added keys (1)
     + termConfig
   Deleted keys (0)
   Updated keys (2)
     ~ attestations
     ~ resources

📊 Dry Run Diff Summary
   Source documents: 2
   Target documents: 2
   Changed documents: 2
   Unchanged documents: 0
   Total added keys: 2
   Total deleted keys: 0
   Total updated keys: 4
✅ [DRY RUN] Would copy 2 tenantSchema documents to tenantSchema in booking-app-prod
💾 Wrote detailed dry-run report to dry-run-pr-production-details.json

📊 Copy Summary:
✅ Successful operations: 2
  - Backup (production): 2 documents would be backed up
  - Update (production): 2 documents would be copied

🎉 tenantSchema backup and update process completed!

@rlho
rlho merged commit 222b5a1 into prod Jul 9, 2026
21 checks passed

This branch was previously deployed

3 inactive deployments
production — b213fee2 Deployed Jul 9, 2026 by rlho via trigger-auto-cancel-declined (production) #3781
staging — b213fee2 Deployed Jul 9, 2026 by rlho via trigger-auto-cancel-declined (staging) #3781
dev — b213fee2 Deployed Jul 9, 2026 by rlho via deploy #729
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant